Codecov Report

Merging #305 into master will increase coverage by 3.23%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #305      +/-   ##
==========================================
+ Coverage   82.87%   86.11%   +3.23%     
==========================================
  Files          20       20              
  Lines        3253     3262       +9     
  Branches      861      864       +3     
==========================================
+ Hits         2696     2809     +113     
+ Misses        404      291     -113     
- Partials      153      162       +9     

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 54cf1b8...12201b9. Read the comment docs.

this is an api breaking change and let's take a decision on this and update the few repos that we have that use pydra

@satra - so you don't want to have it today/tomorrow release.

i mean this is as good a time as any, but perhaps we should ask a few people. because once changed, we would unlikely change it back.

@satra - you're right, should give more time. I wasn't planning to change tutorial before accepting this (pretty sure that won't discover anything new after changes in tests), but let me know if you want me to do it

i think we can have people look at this and if they agree we make another release soon after, but let's leave this out of the immediate release.

@satra - i have to say that I like out current syntax, after all these changes I started thinking that perhaps it could be kept as an option, i.e. if inputs is used, we expect everything to be in the inputs dictionary, but if inputs is not specified than we take kwargs.

@effigies and @oesteban - would love your input on this. i agree with dorota's last comment. that it would make it much easier in most cases to take kwargs as input fields if there is no clash. but allow for inputs keyword if a user choses.

@djarecka - since the issue here is about clashes with potential attributes of the classes. perhaps we can check if the input spec has a field that clashes and in those cases force people to use inputs.

I think that seems fine. I'm very likely to develop patterns where I can be very consistent, whether that's avoiding parameters that clash or always using inputs, but we don't have to make it impossible to do otherwise.

@satra - but perhaps we should not allow for mixing, i.e. some inputs in inputs some in the kwargs

we should not allow for mixing

yes no mixing.

We really let this one fall by the wayside. Going to need to be redone post-#662.